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Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 
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RID  Updates 


•  Purpose 

•  RID  and  INCH 

•  Messaging  Format  for  RID 

9  Define  Extensions  to  IODEF  Model 

•  New  Extension  for  Policy  and  Trace  Continuance 

•  Communication  Mechanism  for  RID  Documents 

•  Security  Considerations 
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Real-time  Inter-network  Defense  (RID) 


•  Trace  Security  Incidents  to  the  Source 

•  Stop  or  Mitigate  the  Effects  of  an  Attack  or  Security  Incident 

*  Facilitate  Communications  between  Network  Providers 
9  Integrate  with  existing  and  future  network  components 

-  Systems  to  trace  traffic  across  a  network 

Intrusion  Detection  Systems 

NetFlow,  Hash  Based  IP  Traceback,  IP  Marking,  etc. 

Network  devices  such  as  routers  and  firewalls 

*  Provide  secure  means  to  communicate  RID  messages 

-  Consortiums  agree  upon  use  and  abuse  guidelines 

-  Consortiums  provide  a  key  exchange  method 

Trusted  PKI,  certificate  repository,  cross  certifications 
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RID  and  INCH 


*  RID  is  used  to  communicate  security  incident  handling 
information  between  CSIRTs  or  NPs 

9  RID  carries  much  of  the  same  data  as  an  IODEF  document 

*  RID  requires  a  few  additional  data  elements 

9  Communication  and  proper  transport  of  messages  is  in  the 
RID  specification 

9  RID  is  now  reformatted  to  use  the  IODEF  specification 

-  Packet  based  format  to  IODEF  document 
9  RID  message  types 

-  XML  IODEF  document  with  RID  extensions 

-  SOAP  Wrapper 

-  Transport  via  BEEP  or  HTTP 
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RID  Extensions  to  IODEF 


•  AdditionalData  Class  from  IODEF  used  to  define  Extensions 

-  IPPacket  Class 

Allows  hex  packets  to  be  stored  in  the  RID  message  in  a  format  that  will  be  expected  by 
the  recipient  of  a  RID  message 

Multiple  packets  may  be  sent  in  a  single  message 

-  NPPath  Class 

Purpose  is  to  identify  the  path  of  the  trace  and  to  avoid  loops 

-  TraceStatus  Class 

Method  for  providing  approval  status  from  upstream  peer  after  a  trace  request  is  made 

-  RIDPolicy 

Method  to  determine  via  RID  messages  if  trace  should  be  continued  between  NPs 
Policy  negotiations  for  RID  messages 

•  Reliability  of  the  trace  type  requested 

-  Some  NPs  may  have  multiple  choices  for  traceback 

-  Method  needed  to  decide  which  of  several  methods  should  be  used  by  the 
percentage  from  the  originator  of  request 

•  Level  of  trace  required 

-  RID  systems  need  to  reference  the  IODEF  expectation  class  to  determine  how 
fast  of  a  trace  mechanism  should  be  used 

-  The  start  time  and  end  time  can  be  used  to  determine  if  a  fast  method  of  tracing 
or  a  slow  and  more  detailed  trace  mechanism  can  be  used 
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RID  Policy 


•  RID  Policy 

-  New  extension  to  ensure  that  policy  information  is  transferred  between 
participating  RID  peers 

-  Policy  information  in  RID  to  prevent  policy  related  issues  from  relying  on  the 
transport  mechanism  for  enforcement 

•  RIDPolicy  Information 

-  Extension  to  define  the  type  of  trace 

IODEF  Method  and  Impact  class  information  should  be  considered  for  the  type  of  traffic 
requested  for  trace  and  the  success  of  an  attack 

Explicit  statement  for  the  type  of  trace  requested  in  case  it  does  not  fit  into  the  category 
of  attack  traffic  and  can  be  linked  to  a  CVE  or  other  identifier 

-  Identifies  where  the  traffic  may  have  policy  issues 

Client  to  NP 

NP  to  client 

Within  a  consortium 

Between  peers 

Between  consortiums 

Across  national  boundaries 

•  Purpose  is  to  try  to  prevent  abuse  of  the  system 

-  Address  security,  confidentiality,  and  privacy  concerns  listed  in  the  draft 
New  extension  created  to  address  issues  raised  at  IETF-59 
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Communicating  RID  Messages 


•  SOAP  Messaging  Wrapper  and  XML  Security 

Method  to  transport  messages 

-  Policy  negotiated  in  RID  message  and  not  wrapper 

-  Provide  integrity,  authentication,  authorization 

XML  digital  signature,  encryption,  and  public  key  infrastructure 

Encryption  of  RID  for  privacy  and  security  reasons  should  be  via  XML  encryption  and 
not  through  the  security  provided  by  a  wrapper  or  higher  level  protocol 

•  Public  Key  Infrastructure 

-  Provided  by  consortiums  linking  network  providers  for  RID  messaging 

•  Message  Types 

-  Trace  Request 

-  Trace  Authorization 
Source  Found 

-  Relay  Request 

•  RID  Systems  Must  Track  the  Requests  by 

-  Incident  Number 

-  Packet  Contents 
Completion  Status 
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Security  Considerations 


•  Consortiums 

-  Agreements  between  entities  involved  in  RID  peering 

-  Provide  a  secure  key  exchange  repository/system  (PKI) 

-  Peering  agreements  and  policies  between  consortiums  and  across 
national  boundaries  or  jurisdictions 

-  Policy  enforced  through  RID  messages  by  stating  level  and  type  of 
trace 

•  System  use  guidelines 

-  Privacy  considerations 

-  Abuse  policies 

-  Use  policies  may  vary  across  national  network  or  consortium 
boundaries 

Automated  method  to  allow  enforcement  of  use  agreements 

•  RID  server  security  policies 

-  Network  based  access  controls 

-  Hardened  systems 

•  Communication  security  considerations  for  the  exchange  of  RID 
messages  and  the  underlying  protocols 
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Summary 


•  Updates  from  the  previous  version 

-  Extended  the  AdditionalData  Class  to  accommodate  the 
needs  of  RID  messaging  and  RIDPolicy 

Extended  information  on  system  use  and  privacy  considerations 

-  PKI  at  the  core  of  the  security  model,  but  provided  by  a 
consortium 

-  Topology  examples  to  address  implementers  questions 

-  DTD  moving  to  schema  format 
9  Near  Future  Update  will  include 

-  SOAP  wrapper  and  more  information  on  XML  Security 

-  May  include  additional  examples  of  other  message  types 

-  Any  suggested  revisions  or  clarifications 

•  http://www.ietf.org/internet-drafts/draft-ietf-inch-rid-OQ.txt 
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